Data center for providing subscriber access to data maintained on an enterprise network

ABSTRACT

A data center for providing access to subscriber information from a remote enterprise network in real-time is presented. The data center includes a data network interface system for interfacing with a data network and a login system, which includes a login server and a data center messaging server. The login server receives a request inputted by a subscriber on a remote access device across the data network to access the subscriber information and authenticates the subscriber and the remote device, while the data center messaging server hosting the subscriber information. Upon authenticating the subscriber and the remote device, the login server, accesses the subscriber information on the data center messaging server and provides the subscriber information to the remote access device in response to the received request.

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application is a continuation of U.S. patent applicationSer. No. 09/438,819, filed Nov. 10, 1999, pending.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] This invention generally relates to the field of communicationsand information network management. More particularly, the presentinvention relates to a novel system that allows remote end users torapidly and securely access information from a variety of subscriberdevices using a centralized remote data center.

[0004] 2. Description of Related Art

[0005] Recent innovations in wireless communication and computer-relatedtechnologies as well as the unprecedented growth of Internet subscribershave provided tremendous opportunities in telecommuting and mobilecomputing. In fact, corporate entities and enterprises are movingtowards providing their workforces with ubiquitous access to networkedcorporate applications and data, such as, for example, e-mail, addressbooks, appointment calendars, scheduling information, etc.

[0006] The problem with providing universal access to proprietaryinformation is one of logistics. For example, it is common for anindividual to keep sets of addresses on different devices, such as workaddresses on a personal computer used at work, personal addresses on ahome computer, and commonly called telephone numbers on a cellulartelephone. Problems arise when the individual is at home and wishes tocall or fax a work colleague, particularly when the individual does nothave access to the work addresses from the home computer or any otheravailable device. Further, different urgent priority items, such asurgent e-mails, may be unavailable to a subscriber for an extendedperiod of time if the subscriber is equipped only with a personaldigital assistant (PDA) and a cellular telephone unable to receivee-mail.

[0007] Along with the problem of maintaining data in various locations,users frequently have access to different devices, each having differentdata access abilities and requirements. For example, certain cellulartelephones have speed dial or commonly called telephone numbers, but donot have the ability to receive e-mail. Certain cellular telephonehandsets have the ability to receive alphanumeric pages, but somecellular service providers do not support this feature while others do.Also, many PDAs do not have the ability to receive over-the-airtransmissions, but can synchronize with a database, such as a databaseassociated with a personal computer and/or network. Other PDAs have theability to receive and edit e-mail messages. Some systems or networksallow a subscriber to download her e-mail headers to a remote device andread some portion or all of the e-mail. After reading the e-mail on theremote device, some systems delete the e-mail while others maintain thee-mail on the system until read or deleted at the home system. Hence theability for a subscriber to access, maintain, and dynamically utilizeinformation is heavily dependent on the input device employed by thesubscriber.

[0008] Further, certain organizations limit access to workers having aneed to know the information maintained. For example, many corporationscontrol e-mail using a dedicated server having restricted access,including using firewalls and encryption. Access to this informationrequires making the information available under conditions imposed andmaintained by the corporation.

[0009] For purposes of this application, a corporation or other entity,public private, or otherwise, is referred to as an “enterprise.” As usedherein, an enterprise represents any entity maintaining or controllinginformation at a remote location from a subscriber. Examples ofenterprises include a secure corporate network, a dedicated server, or apublicly accessible web site network.

[0010] Other enterprises may be employed which maintain and controlcertain information as may be appreciated by those of skill in the art.

[0011] While certain systems have been employed to provide access toinformation maintained at an enterprise, none have provided for accessby multiple devices including PDAs, cellular telephones, personalcomputers, laptops, MICROSOFT® Windows CE devices, and so forth.

[0012] Further, those systems discussed in the literature that provideinformation access to users employing a limited set of input deviceshave suffered from accessibility and data latency problems.Accessibility issues involve providing access to the information by onlyoffering access through a corporate Intranet or other internal accessscheme. A subscriber wishing to review his or her e-mail on a laptopborrowed from a colleague frequently is denied access to the corporateinformation. Further, data latency universally inhibits the ability toaccess data. Users desire a fast response to the information theydesire, and information on any device that takes longer than fifteenseconds to load is undesirable.

[0013] Additionally, certain enterprises wish to have control overinformation maintained on their networks, including maintaining passwordand account information for the enterprise users. It is thereforeundesirable for the enterprise to offer sensitive data, such assubscriber information and passwords, to outside parties where the datamay be compromised. Security issues, such as corporate firewalls andencryption of data, must in many instances be maintained and controlledby the enterprise rather than a third party.

[0014] Certain enterprises also have particular needs and preferences.For example, some corporate enterprises may maintain a network thatinterfaces with offices in different countries, and depending on theperson accessing the information, he or she may have a particularlanguage preference. Certain enterprises also find it highly desirableto have a reconfigurable interface to provide updated graphics,information, and presence to network users. These subscriber interfacesmay change rapidly in some industries. A system offering informationaccess should therefore be readily reconfigurable and offer subscriberinterfaces structured for the enterprise for use on a variety of inputdevices.

[0015] Such a system should be relatively easy to set up and maintain,and use readily available hardware and software wherever possible.Further, the system should provide for data access tracking andefficient security and authorization.

[0016] It is therefore an object of the current invention to provide asystem for offering convenient and efficient access to data, includinge-mail, calendar/date book, and addresses. These terms are commonlyknown in the art, wherein e-mail represents electronic mail deliverablein a recognized format, including attachments and other electronic mailattributes. Calendar/date book data represents dates of meetings,appointments, holidays, or other noteworthy events maintained in asearchable database type format. Addresses represent informationassociated with contacts, such as the contact's name, title, company,business address, business phone number, business fax number, homeaddress and/or phone number, cellular phone number, e-mail address, andso forth. Access to the information should preferably be providedthrough a central location.

[0017] It is a further object of this invention to provide for access tothe desired information using any of a variety of input devices,including but not limited to a personal computer, a laptop computer, aPDA, a cellular telephone, a two-way pager, and a MICROSOFT® Windows CEdevice.

[0018] It is still a further object of the present invention to providea system that recognizes the type of device addressing and requestingthe information and to provide the information to the device in a properformat in accordance with the preferences of the enterprise transmittingthe information.

[0019] It is another object of the current invention to provide acentral location for enabling a series of users to access information atvarious enterprises when said users employ various input devices. Such acentral location should offer relatively robust access to theinformation desired, offer security for information maintained on theenterprise such as subscriber data and passwords, and provide forauthentication and access tracking.

[0020] It is yet another object of the current invention to provide aninterconnection between a central data location and an enterprise suchthat the interconnection can quickly, reliably, and efficiently transferinformation, such as e-mail, calendar, and address data, between thecentral data location and the enterprise.

[0021] It is a further object of the current invention to provide aremote enterprise architecture that supports inquiries from andresponses to the central data location for use in a multiple subscriberand multiple input device data access scheme. The remote enterprisearchitecture should permit rapid access to the information andtransmission of the information while simultaneously maintainingfirewall, security, and encryption requirements.

[0022] It is still a further object of the current invention to providearchitectures, which are reliable and easy to use from both a softwareand hardware standpoint, and utilize where possible existing componentsto minimize system costs.

[0023] It is yet a further object of the current system to provide asubscriber interface that is readily reconfigurable by an enterprisemaintaining the information. Further, the subscriber interface shouldpreferably provide enterprise data on various input devices and takeinto account enterprise and subscriber preferences when interfacing witha subscriber.

[0024] It is another object of the current invention to provide abusiness model for supplying users with access to e-mail, calendar, andaddress information in a multiple input device environment when thedesired information is maintained at a remote enterprise.

SUMMARY OF THE INVENTION

[0025] Accordingly, there is herein provided a data center that providesa central location for accessing, transmitting, and maintaining desiredsubscriber information, including e-mail, calendar, and contacts. Thedata center includes a login site and associated SQL server, anenterprise gateway server and associated SQL system. The arrangementdisclosed herein provides for remote login by users employing any of anumber of subscriber input devices. The architecture provides for twolevels of authentication, including an initial authentication for thedata center and a pass through authentication to the enterprise network.The data center also preferably includes security, such as firewallhardware, and has the ability to translate received CDO commands intoXML commands.

[0026] The data center permits the authentication of a subscriber andaccess to a remote enterprise having a scalable, reliable, and securedata platform, such as MICROSOFT® Exchange Server.

[0027] Access to the remote enterprise is made through a dedicatedconnection such as an IPSEC or PPTP tunnel arrangement. The enterprisenetwork is preferably maintained by the party controlling theinformation and the connection, and thus the system supports access tothe remote enterprise through the data center without the data centerreceiving and translating the subscriber information.

[0028] The remote access device transmits or receives information over adata link, which is connected to a data center. The data center offers acentral location for accessing and processing information from variousremote enterprise networks. The data center includes at least one loginserver, configured as a web server (e.g., MICROSOFT® IIS), having accessto at least one attributes database server (e.g., SQL server). The loginserver identifies and authenticates the subscriber and verifies that thesubscriber is associated with a particular enterprise. The login serverrefers to the attributes database server for the data necessary toperform these tasks, and thus the attributes database server performsdata storage for account access purposes. The login runs individualactive server pages that provide the requested information back acrossthe data link to the subscriber. The data center may send data through adedicated connection, which is preferably an IPSEC tunnel through theInternet, a PPTP connection via the Internet, or it may send datathrough a non-Internet WAN transport mechanism. The Internet provides apowerful and readily accessible data transmission media. Addition ofenterprise networks or data centers to an arrangement employing theInternet is relatively simple. The data link may also employ theInternet for subscriber access to the data center.

[0029] Other objects, features, and advantages of the present inventionwill become more apparent from a consideration of the following detaileddescription and from the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The accompanying drawings, which are incorporated in andconstitute a part of this Specification, illustrate an embodiment of theinvention and, together with the description, explain the objects,advantages, and principles of the invention. In the drawings:

[0031]FIG. 1 is a conceptual diagram representing the major componentsof the system;

[0032]FIG. 1A is a high level block diagram depicting the basic elementsof an embodiment of the present system;

[0033]FIG. 1B is a high level block diagram depicting various elementsof an exemplary communication system interfacing with a remote datacenter;

[0034]FIG. 1C is a high level block diagram depicting the architectureof a remote data center;

[0035]FIG. 2 is a functional block diagram depicting the authenticationprocess;

[0036]FIG. 3 is a high level block diagram illustrating the basicelements of the EGS;

[0037]FIG. 4 is high level diagram depicting the connectivity between adata center and a plurality of enterprise network servers;

[0038]FIGS. 5A, 5B are block diagrams illustrating embodiments of theimplementation of a Virtual Private Network interconnecting a datacenter and a enterprise network;

[0039]FIG. 6 is a diagram depicting the architecture of the RGS softwarecomponents;

[0040]FIGS. 7A and 7B are diagrams depicting alternative embodiments ofthe communications between a messaging server and an EGS; and

[0041]FIG. 8 illustrates the customization initialization procedure.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0042] The following detailed description of the embodiments of thepresent invention refers to the accompanying drawings that illustratethese. Other embodiments are possible and modifications may be made tothe embodiments without departing from the spirit and scope of theinvention. Therefore, the following detailed description is not meant tolimit the invention. Rather the scope of the invention is defined by theappended claims.

[0043] It will be apparent to one of ordinary skill in the art that anembodiment of the present invention, as described below, may be realizedin a variety of implementations, including the software, firmware, andhardware of the entities illustrated in the figures (i.e., remote accessdevice 104, BSC/MSC 106 and IWF 108). The actual software code orcontrol hardware used to implement the present invention is not limitingof the present invention. Thus, the operation and behavior of thepresent invention will be described without specific reference to theactual software code or hardware components. Such non-specificreferences are acceptable because it is clearly understood that a personof ordinary skill in the art would be able to design software andcontrol hardware to implement the embodiment of the present inventionbased on the description herein.

[0044]FIG. 1 presents a conceptual overview of the design of the currentsystem. From FIG. 1, a subscriber has access to an input device, whichmay be one from a class of input devices 10 including, but not limitedto, a cellular telephone 11, a personal digital assistant (PDA) 12, aMICROSOFT® Windows CE device 13, a desktop personal computer 14, or alaptop personal computer 15. Other devices may be employed, such as atwo-way paging device, while still within the scope of the presentinvention. The important characteristic of the class of input devices 10is that each device must have the ability to receive information.

[0045] The input device transmits or receives information over a datalink 16, such as a telephone line, dedicated computer connection,satellite connection, cellular telephone network, the Internet, or otherdata connection. The data link 16 is connected to a data center 17,which offers a central location for accessing and processing informationfrom various remote enterprise networks 22. Data center 17 providesusers with access to information or data maintained at the enterprisenetworks 22. The data center 17 includes at least one web server 18(e.g., MICROSOFT® Internet Information Server [IIS]) having access to atleast one attributes database server (e.g., Structured Query Language[SQL] server) 19. The IIS server 18 identifies and authenticates thesubscriber and verifies that the subscriber is associated with aparticular enterprise. The IIS server 18 refers to the SQL server 19 forthe data necessary to perform these tasks, and thus the SQL server 19performs data storage for account access purposes. The IIS servers 18process individual active server pages, or ASPs, that provide therequested information back across data link 16 to the user orsubscriber. The data center 17 transmits data through a dedicatedconnection 20, which is preferably an IPSEC tunnel through the Internet,or a PPTP connection via the Internet. The dedicated connection 20 isprovided through data transmission media 21, which may be the Internet,a Wide Area Network (WAN), or any other media used for servercommunication. The dedicated connection 20 provides the robustnessnecessary to update the subscriber and provide information in areasonable time period. Use of a connection that is not dedicated canresult in delays and service disruptions, and the Internet provides anexample of a powerful and readily accessible data transmission media.Addition of enterprise networks 22 or data centers 17 to an arrangementemploying the Internet is relatively simple. Note also that data link 16may also employ the Internet for subscriber access to the data center17.

[0046] In operation, the subscriber must first access the data center 17using an access arrangement, such as a password verifying his or heridentity. The subscriber makes a request into the subscriber device,such as a cellular telephone, to view data, such as his or her e-mail.The IIS server 18 receives the request via the data link 16 and passesthe request through the dedicated connection 20 and on to the enterprisenetwork 22. The enterprise network 22 processes the request for e-mailand obtains the necessary data pursuant to the subscriber preferencesprovided by the SQL server in the data center 17. For example, thesubscriber is presumed to have established that if he or she desirese-mail through his or her cellular telephone, the information providedshould be only the first ten messages, alphabetized by the last name ofthe sender. In such a situation, the enterprise network 22 obtains therequisite information and transmits the data back through the dedicatedconnection 20, to the data center 17, and to the subscriber via datalink 16 to the requesting subscriber input device. To accomplish this,the enterprise network 22 must include a server having a scalable,reliable and secure data access platform, such as MICROSOFT® ExchangeServer, for ready access to the requested e-mail, calendar, or contactinformation.

[0047]FIG. 1A illustrates an embodiment of the present invention. Theembodiment allows subscribers to securely and remotely access acentralized data center 190, which acts as an intermediary to facilitatesubscriber information residing in an independent enterprise network 403in real time. In one implementation, a subscriber, by virtue of a remoteaccess device 104, makes a request, across a network 100, to a datacenter 190, to supply subscriber information (e.g., messaging andcollaboration information, such as electronic mail, appointmentcalendars, address/phone books) located in an enterprise network 403.The data center 190 receives the request, authenticates the subscriber,accesses the enterprise network 403, establishes a secure session withthe enterprise network 403, retrieves the subscriber information, andformats the information in accordance with the display capabilities ofthe remote access device 104. The remote access device 104 may beconnected to a “wireline” network (e.g., personal computer, kiosk, etc.)or may be connected to a wireless network (e.g., cellular phones,personal digital assistants [PDAs], MICROSOFT® Windows CE device, etc.).

[0048] In another embodiment, as indicated by FIG. 1A, the data center190 itself provides a central repository for the subscriber information(dashed-line). As such, the subscriber initiates a request in the remoteaccess device 104 and the data center 190 receives the request,authenticates the subscriber, accesses the subscriber information, andformats the information in accordance with the display capabilities ofthe remote access device 104.

[0049] The features and details of the various embodiments of theinvention will be described below.

[0050] 1. Remote Access Devices

[0051] The remote access and retrieval of subscriber informationresident in the enterprise network 403 is initiated by requesting theinformation on a remote access device 104. Generally, these requests areinitiated by inputting an address on a browser (or micro-browser)interface of the remote access device 104. The address partiallyidentifies the enterprise network 403 that the subscriber is associatedwith (i.e., company, employer, etc.) and the address may be in the formof an HTTP URL (Hypertext Transfer Protocol Uniform Resource Locator).The remote access devices 104 have communication capabilities, allowingthem to interface with wireless and wireline communication networks. Inone implementation, the remote access devices 104 are wireless andinclude devices that are well-known in the art, such as hand-heldwireless phones, Personal Digital Assistants (PDAs), MICROSOFT® WindowsCE devices, and mobile computers. Such devices operate in wirelessnetworks that include, but are not limited to PSTN, CDPD, CDMA/IS-95,TDMA/IS-136, MOBITEX, and GSM networks.

[0052] In addition, these remote access devices 104 generally havegraphical displays to accommodate their browsing capabilities. Theremote access devices may use different markup languages to interpret,format, and display the contents of the retrieved subscriberinformation. Such languages may include Hypertext Markup Language(HTML), Handheld Markup Language (HDML), Extensible Markup Language(XML), Extensible Stylesheet Language (XSL), and Wireless MarkupLanguage (WML).

[0053] 2. Network Access to Data Center

[0054] As stated above, the remote access devices 104 have communicationcapabilities to interface with a variety of communication networks,including wireless communication systems. FIG. 1B illustrates the basicelements of a wireless implementation of network 100 in FIG. 1A.Artisans of ordinary skill will readily appreciate that these elements,and their interfaces, may be modified, augmented, or subjected tovarious standards known in the art, without limiting their scope orfunction.

[0055] In one implementation, the remote access device 104 firstcommunicates and sustains a session with a Base StationController/Mobile Switching Center (BSC/MSC) 106 via the wirelessinterface (i.e., air-link) U_(m) in accordance with a wirelesscommunication network scheme, such as CDPD, CDMA/IS-95, TDMA/IS-136,MOBITEX, and GSM. The BSC/MSC 106 employs a transceiver to transmit tothe remote access device 104 (i.e., forward link) and receive from theremote access device 104 (i.e., reverse link), consistent with thewireless network scheme. The BSC/MSC 106 supervises, manages, and routesthe calls between the remote access device 104 and the Inter-WorkingFunction (TWF) 108.

[0056] The IWF 108 serves as a gateway between the wireless system 100and other networks. The IWF 108 is coupled to the BSC/MSC 106 and inmany cases it may be co-located with the BSC/MSC 106. The IWF 108provides the session between the remote access device 104 and theBSC/MSC 106 with an IP address, consistent with the well-known InternetProtocol (IP).

[0057] As is well known in the art, the IP protocol is a network layerprotocol that specifies the addressing and routing of packets(datagrams) between host computers and specifies the encapsulation ofdata into such packets for transmission. Addressing and routinginformation is affixed in the header of the packet. IP headers contain32-bit addresses that identify the sending and receiving hosts. Theseaddresses are used by intermediate routers to select a path through thenetwork for the packet towards its ultimate destination at the intendedaddress. Providing the session between the remote access device 104 andthe BSC/MSC 106 with an IP address, the session can be intelligentlyrouted to other networks.

[0058] The IWF 108 is subsequently coupled to a system router 110, whichinterfaces with other networks, such as the Public Switched TelephoneNetwork (PSTN) and other Wide Area Networks (WANs) providing Internet-or secure/unsecure Intranet-based access.

[0059] 3. Data Center Configuration and Host and Enterprise Operations

[0060] Data center 190 acts as an intermediary to remotely and securelycollect, process, and format the information residing in the enterprisenetwork 403 and to present the information on the remote access device104 in real time. Generally, the desired information will be stored in aspecialized database/messaging server within the enterprise network 403,such as, for example, MICROSOFT® Exchange Server 5.5. Such a databasehosts electronic mail, address books, appointment calendars, and iscapable of groupware functionality.

[0061] As shown in FIG. 1C, the data center 190 comprises an interfacenetwork 120, a Login subsystem 140, and a Service subsystem 160. Theinterface network 120 employs perimeter router 122 to interface with thewireless communication system 100, which transports the IP datagramsbetween the remote access device 104 and the BSC/MSC 106. The interfaceis achieved by virtue of a WAN topology and may employ well-knownAsynchronous Transfer Mode (ATM), Frame Relay, dedicated DS-1 (1.544Mbps), DS-3 (45 Mbps) and other topologies. The perimeter router 122 mayconnect to the data center 190 through a firewall 124 to provide anadded level of protection and further limit access to data center 190from the Internet. Artisans of ordinary skill will readily appreciatethat generally, firewalls are well-known security mechanisms thatprotect the resources of a private network from users of other networks.For example, enterprises that allow its own subscribers to access theInternet may install a firewall (or firewalls) to prevent outsiders fromaccessing its own private data resources and for controlling whatoutside resources its own subscribers have access to. Basically,firewalls filter incoming and outgoing network packets to determinewhether to forward them toward their destination.

[0062] The firewall 124 interfaces with the login subsystem 140. Asdepicted in FIG. 1C, the login subsystem 140 comprises a login server(LS) 142, and an attributes database server 144. In one implementationan external disk array 146 may be used to store the databaseinformation.

[0063] The firewall 124 is connected to the LS 142. The LS 142 providesa centralized login site for all subscribers and provides the firstlevel of subscriber authentication. As such, all sessions stemming fromsubscribers' remote access devices 104 are first handled by the LS 142.The LS 142 is configured as a web server, such as MICROSOFT® InternetInformation Server (IIS) for remote corporate enterprise access. The IISis designed to be tightly integrated with MICROSOFT® Windows NT Server,resulting in faster Web page serving. The LS 142 may be implemented as asingle IIS or as a cluster of IISs with load balancing and faulttolerant features provided by MICROSOFT® Windows Load Balancing Service(WLBS).

[0064] The LS 142 communicates with an attributes database server 144,which provides, inter alia, subscriber credential profiles toauthenticate each subscriber. (The attributes database server 144 mayalso contain subscriber display preferences and customized enterprisedisplay features). The subscriber credentials are stored in the externaldisk array 146, which is coupled to the attributes database server 144.The attributes database server 144 may be configured as a StructuralQuery Language (SQL) database server and may be implemented as a singleserver or as a cluster of servers with cluster management provided byMICROSOFT® Cluster Server (MSCS).

[0065]FIG. 2 illustrates the LS 142 authentication process. As shown inblock B205, subscribers input an address or URL, corresponding to anenterprise network or sub-network therein, in the browser interface oftheir respective remote access devices 104. Generally, inputting a validURL pointing to a particular enterprise network 403 in the remote accessdevice 104 browser establishes a session between the browser and the LS142.

[0066] The LS 142 responds by sending a message back to the remoteaccess device 104 browser, prompting the subscriber to supply logincredentials and a personal identification number (PIN), as indicated inblock B210. The login credentials may include subscriber-name andpassword while the PIN is used as a second level of authentication bythe enterprise network 403. In block B215, the LS 142 examines the logincredentials. The LS 142 then determines, as shown in block B220, whetherthe account is locked out. As a security measure, an account is lockedout if a predetermined number (e.g., 3) of successive bad login attemptsoccur. If the account is locked out, the LS 142, in block B225 informsthe subscriber that the account has been locked out. LS 142 examines theinformation. If the account has not been locked out, the LS 142 advancesto block B230.

[0067] In block B230, the LS 142 compares the examined login credentialswith the subscriber credential profile. The subscriber credentialprofile contains subscriber-specific information, which resides in theattributes database server 144. In block B230, the LS 142 determineswhether a match exists between the session-provided information and thestored credential information. If a match does not exist, the LS 142progresses to block B235, where it first determines whether the currentrequest constitutes the third bad login attempt. If so, the account islocked, as stated above with respect to block B220. If the request doesnot constitute the third bad attempt, then the LS 142 advances to blockB245, where it requests the subscriber to re-input the login informationand PIN.

[0068] If a match does exist between the session-provided informationand the stored credential information, the LS 142 associates theidentified subscriber with a corresponding enterprise network 403 (asindicated by the information contained in the URL, subscribercredentials, or a combination thereof), thereby achieving the firstlevel of authentication, as depicted in block B250. It is noted that theexistence of a subscriber in the attributes database server 144 ispreferably keyed to both the entered subscriber-name and the enterprisenetwork 403 associated with the subscriber. Accordingly, differententerprise networks 403 can have the same subscriber-name.

[0069] Upon successfully authenticating the subscriber, the LS 142, inblock B260, encodes the session with a subscriber-specific,session-specific, and time/date-specific enterprise access code (EAC).This is achieved by providing the browser on the remote access device104 with the EAC as well as the address information (i.e., URL) for thededicated server (i.e., EGS), within the service subsystem 160, thatpoints to the enterprise network 403. The LS 142 then informs thededicated server of the impending session and provides the server withthe EAC. Subsequently, in block B270, the LS 142 dynamically redirectsthe session to the dedicated server and upon recognizing the EACsession, the dedicated server grants access to the redirected encodedsession.

[0070] As depicted in FIG. 1C, the data center 190 includes a servicesubsystem 160. The service subsystem 160 comprises a plurality ofdedicated web servers, wherein each server accesses and services aspecific enterprise network and a plurality of attributes databaseservers 166 which service the dedicated servers. These dedicated webservers are referred to as enterprise gateway servers (EGSs) 164. FIG. 3illustrates that each EGS 164 comprises a MICROSOFT® InternetInformation Server (UIS), a plurality of application interfaces 307, andan associated attributes database server 166. Much like the LS 142, theEGS 164 may be implemented as a single IIS or as a cluster of IISs withload balancing and fault tolerant features provided by MICROSOFT® WLBS.

[0071] The application interfaces 307 provide the functionality andinteroperability between the EGS 164 elements, the LS 142, and theattributes server 144. The application interfaces 307 comprise aplurality of COM (Component Object Model) objects 308 and Active ServerPages (ASPs) 306 that are specifically designed to achieve EGS 164functionality. The COM objects 308 (described in more detail below) arereusable program building blocks that can be combined with othercomponents in a distributed network to form functional applications. TheASPs 306 are server-side scripts that are capable of generating markuplanguages, including but not limited to HTML, HDML, WML, XSL, XML, etc.,to perform the dynamic rendering of web content which can be deliveredto any browser. The ASPs 306 work with in conjunction with the COMobjects 308 to capture the contents of the enterprise network 403information and dynamically output the information on the browserdisplay of the remote access device 104.

[0072] The ASPs 306 are designed to first retrieve the subscriberdisplay preferences from the attributes database server 144 to determinehow to render the information on the browser display of the remoteaccess devices 104. These preferences include attributes relating to theformatting, filtering, and sorting of the information. By way ofexample, suppose a subscriber wishes to retrieve e-mail information fromhis inbox, which is stored in the messaging database server (e.g.,MICROSOFT® Exchange Server 5.5) within the enterprise network 403. Afterinputting the necessary HTTP URL in the remote access device 104 toaccess the enterprise network 403, a session is established with the LS142. The HTTP header of the request contains information identifying theparticular remote access device 104 used in entering the URL. An ASP 306exploits this information to determine what type of markup language(e.g., HTML, HDML, WML, XSL, XML, etc.) to use in rendering the displayof the desired e-mail information.

[0073] As stated above, after establishing subscriber authentication,the LS 142 redirects the session with a URL that points to an ASPassociated with a dedicated EGS, along with the type of informationsought. In this case, the redirected URL may read as“enterprise₁₃network₁₃A/email.asp”, where “enterprise₁₃network₁₃A” isthe name of the enterprise network 403 in which the EGS 164 points toand “email.asp” points to the ASP 306 responsible for retrieving andincorporating the subscriber-specified preferences. These preferencesidentify how the e-mail information in the enterprise network 403appears on the browser display of the remote access device 104. Forexample, the subscriber may want the unread inbox entries to be renderedfirst, followed by the subject of each entry, followed by the initialsof the sender, followed by the time and date of transmission, etc. Inone implementation, these preferences may be stored in the attributesdata server 164 within the service subsystem 140; in anotherimplementation, these preferences may be stored in the attributes dataserver 144 within the login subsystem 140.

[0074] Before retrieving the desired information from the enterprisenetwork, the ASPs 306 are also responsible for validating the sessionbetween the EGS 164 and the enterprise network 403. After beingre-directed to a dedicated EGS 164, a Virtual Private Network (VPN)connection is established to the enterprise network 403 and the sessionis extended thereto. As described in more detail below, the ASPs 306must determine whether the VPN connection and the session between theEGS 164 and the enterprise network 403 are valid.

[0075] Finally, the ASPs 306 retrieve the desired information in rawform from the enterprise network 403 and format the raw information inaccordance with the subscriber preferences and remote access 104 devicelimitations.

[0076] In addition to acting as an intermediary, the data center 190 mayact as a central repository for the subscriber information. In thismanner, the data center 190 provides subscribers with “enterprise-like”functionality by hosting subscriber information (e.g., such as e-mail,calendar, and phone book information) that would otherwise be stored inan enterprise network 403. This may be achieved by incorporating amessaging server, such as MICROSOFT® Exchange Server 5.5, within thedata center 190.

[0077] Much like the “intermediary” case, the subscriber initiates arequest in the remote access device 104 and the data center 190 receivesthe request, establishes a session with the LS 142, and authenticatesthe subscriber. However, as indicated in FIG. 1C, instead of the LS 142re-directing the session to an EGS 164 connected to a remotely-situatedenterprise network 403, the LS 142 accesses the desired subscriberinformation from the local messaging server 148 within the data center190 that hosts such information. One implementation includesre-directing the session to a web server 147, which is coupled to thelocal messaging server 148, in a manner similar to the EGS 164. Byvirtue of the application interfaces (similar to the EGS applicationinterfaces 307) designed to the provide functionality between the LS142, the attributes server 144, and the messaging server 148, thedesired information is retrieved and rendered in accordance with thedisplay capabilities of the remote access device 104.

[0078] Further, based on the information received from the remote accessdevice 104, including the HTTP header of the request, the loginsubsystem 140 determines the type of remote access device addressing thedata center 190. The login subsystem 140, particularly the login server142, translates the HTTP header received and provides data and asubscriber interface in accordance with that device type. For example,if the subscriber has indicated her preference for receiving ten e-mailheaders when accessing the system with her remote access device 104, andthe login server 142 receives the HTTP header and a request for e-mail,the system will only seek to transmit ten e-mail headers for thesubscriber.

[0079] 4. Data Center and Enterprise Network Interaction

[0080] As previously discussed, consistent with an aspect of the presentinvention, the data center 190 retrieves data requested by remote accessdevices 104 from an enterprise network 403 and returns the requesteddata, in real time, to the remote devices 104 (i.e., the data centeracts as an intermediary). A more detailed description of the interactionof the data center 190 with the enterprise network 403 will now bedescribed with reference to FIGS. 4-7.

[0081]FIG. 4 is high level diagram of data center 190 coupled, vianetwork 402, to a plurality of enterprise network servers 403. Network402 may be a network, such as the Internet or a proprietary local areaor wide area network. Data center 190 links multiple heterogeneousremote devices 104 to one of enterprise network servers 403. At therequest of one of remote devices 104, data at an associated enterprisenetwork server 403 is transferred over network 402 to data center 190,where it is converted to a form suitable for display by the requestingremote device.

[0082] Each enterprise network server 403 is a computer or network ofcomputers managed by a corporation or other entity that implementscorporate messaging and collaboration applications such as email,calendar, or contact information management applications. Theseapplications are implemented by messaging server 410, which may be adedicated messaging and collaboration server such as a server runningMICROSOFT® Exchange Server 5.5 on top of the MICROSOFT® Windows NToperating system. MICROSOFT® Exchange Server and MICROSOFT® Windows areavailable from MICROSOFT® Corporation, of Redmond, Wash. Other knownimplementations of the messaging and collaboration servers mayequivalently be used.

[0083] Remote Gateway Servers (RGS) 415 are preferably implemented asservers that act as an intermediary between messaging servers 410 anddata center 190. Although the messaging servers 410 could communicatedirectly with data center 190, remote gateway servers 415 provide alayer of abstraction between the messaging servers and the data center190 that enables more efficient communication when communicating over a“slow” network such as the Internet. RGSs 415 are described in moredetail below. RGSs 415 may optionally not be used, in which case, themessaging servers 410 communicate could communicate directly with datacenter 190. For the reasons discussed below with reference to FIGS. 7Aand 7B, this has been found to be a less efficient implementation.

[0084] If network 402 is a public network, such as the Internet, datatransmitted over network 402 is at risk of being intercepted ormonitored by third parties. To avoid this problem, the data may beencrypted at its transmission site (e.g., data center 190 or enterprisenetwork server 403), and correspondingly decrypted at its receptionsite. By encrypting all data transmitted over network 402, data center190 and enterprise server 403 effectively communicate with one anotheras if they were on a private network. This type of encrypted networkcommunication is called a virtual private network (“VPN”).

[0085]FIGS. 5A and 5B are block diagrams illustrating embodiments of theimplementation of a VPN between data center 190 and enterprise network403. The VPN is implemented by encrypting information transmittedbetween EGS 164 and its corresponding RGS 415 on enterprise networkserver 403.

[0086] As shown in the embodiment of FIG. 5A, EGS 164 encrypts thetransmitted data using software 510 running on the EGS. The encrypteddata is transmitted over network 402 and decrypted by dedicated VPNserver 515. Data flowing from enterprise network server 403 to datacenter 190 is similarly encrypted at VPN server 515 and decrypted bysoftware 510. Firewall 520 may optionally be implemented in conjunctionwith VPN server 515 to limit unauthorized outsiders from accessing theprivate data resources of enterprise network 403 and to control whatoutside resources users at enterprise 403 have access to. Firewalls arewell known in the art.

[0087] One example of appropriate encryption/decryption software 510 issoftware that implements the well-known Point-to-Point TunnelingProtocol (PPTP). Although PPTP software 510 is shown executing on a VPNserver 515 and EGS 164, it may alternatively be implemented in specialpurpose PPTP routers or other network devices.

[0088]FIG. 5B illustrates another embodiment implementing a VPN betweendata center 190 and enterprise network 403. This embodiment is similarto the one described with reference to FIG. 5A, the primary differencebeing that the IPSEC (Internet Protocol Security) standard is used toencrypt/decrypt data instead of the PPTP standard. As shown, encryptionusing IPSEC is implemented by a pair of complementary routers 525.

[0089] The IPSEC standard is known in the art. In contrast to the PPTPstandard, the IPSEC standard can provide encryption at the session layeror the network packet processing layer. PPTP provides encryption at thesession layer. Additionally, the IPSEC standard offers considerably moreoptions in the implementation of bulk encryption or hash algorithms.

[0090] RGS 415 communicates with data center 190 through the VPN.Although RGS 415 may be typically present at the same location as thecorporate network, RGS 415 and data center 190 are preferably givenlimited access to messaging server 410 as well as any other corporateservers. In particular, RGS 415 is only given the authority tocommunicate with messaging server 410 to the extent necessary toretrieve and store data related to the messaging and collaborationapplications implemented by messaging server 410. Thus, even though RGS415 may be given limited access to messaging server 410 and the rest ofenterprise network 403, it is generally physically located at the siteof the enterprise network 403.

[0091]FIG. 6 is a diagram of a more detailed architectural view of thesoftware components used to implement RGS 415.

[0092] As shown, RGS 415 provides a MAPI (Messaging ApplicationProgramming Interface) interface 602. MAPI 602 is a MICROSOFT® Windowsprogram interface that enables software objects on RGS 415 tocommunicate with a MAPI-compliant information store, such as MICROSOFT®Exchange messaging server 410. MAPI 602 provides the low level interfacebetween RGS 415 and messaging server 410. MAPI 602 accesses messagingserver 410 based on commands from CDO (Collaboration Data Objects)object 604. CDO 604 is an object in the COM (Component Object Model)framework for the development of component software objects. COMprovides the underlying services of interface negotiation, life cyclemanagement (determining when an object can be removed from a system),licensing, and event services (putting one object into service as theresult of an event that has happened to another object). MAPI, the COMframework, and the CDO object are all available from MICROSOFT®Corporation.

[0093] CDO 604, in operation, processes requests from data center 190 toaccess messaging server 410. Typical CDO requests include requests suchas: retrieve the message object for a particular email of a particularsubscriber, retrieve the subject of the email, and retrieve the time theemail was sent. For each of these requests, CDO 604 accesses messagingserver 410, retrieves the requested information, and returns theinformation to the requesting entity.

[0094] Objects in the conventional COM framework, such as CDO 604, arelimited to communicating with other objects on the same server. COM maybe extended to access and use resources present at server programobjects on other computers in a network using the DCOM (DistributedComponent Object Model) framework. DCOM is available from MICROSOFT®Corporation.

[0095] CDO 604, operating under DCOM, may be stretched across network402 so that requests for messaging server 410 are initiated by a CDOobject resident in EGS 164. This implementation is conceptuallyillustrated in FIG. 7A, in which CDO 701 is shown communicating directlywith messaging server 410 across the Internet. However, because CDO 701generates multiple individual requests 705 for what can often berepresented by a single request (e.g., CDO 701 generates separatenetwork requests to retrieve the subject and the time that an email issent, while practically, these requests may both be submitted at thesame time), delays can occur when accessing messaging server 410. Inparticular, when, as shown in FIG. 7A, CDO 701 is located across arelatively slow or unreliable network such as the Internet, generatingmultiple requests at CDO 701 can cause significant delays in the overallresponse time. For example, if there is a quarter second delayassociated with transmitting a request over the Internet, one requestfor a message from message server 410 may be acceptable, while 40partial requests for the same message may result in an unacceptably longdelay to retrieve the message.

[0096] Consistent with an aspect of the present invention, a DCOM stubobject 605, executing locally on RGS server 415, and a DCOM proxy object607, executing on EGS server 164, introduce a layer of abstractionbetween CDO object 604 and EGS server 164. More particularly, DCOM stub605 and DCOM proxy object 607 communicate with one another over network402 using a higher level, less messaging intense protocol than that usedby CDO 604 when communicating with messaging server 410. Instead ofissuing multiple requests over network 402 to retrieve a particulare-mail's header, time stamp, priority, and body, DCOM proxy 607 mayissue a single aggregate request for all the information associated withone email, or for the first ten emails. DCOM stub 605 receives thesingle request from DCOM proxy 607 and converts it into the appropriateCDO calls. Data received back from CDO 604 is similarly aggregated intothe higher-level protocol and transmitted back across network 402 toDCOM proxy 607. Because CDO 604 executes locally with messaging server410, multiple calls to the messaging server do not significantly slowsystem response time.

[0097] In addition to handling CDO call aggregation, DCOM proxy 607 andDCOM stub 605 manage the connection over network 402. Once EGS 164instantiates DCOM proxy 607, DCOM proxy 607 establishes a dedicated VPNsession connection (“tunnel”) 608 between DCOM proxy 607 and DCOM stub605. After establishing a VPN connection, DCOM stub 605 receives thesubscriber's PIN from DCOM proxy 607. The PIN is passed to LightweightDirectory Access Protocol (LDAP) object 609, which retrieves a locallystored copy of the subscriber's PIN and compares it to the copy receivedfrom enterprise gateway server 164. By comparing PINs at the enterprise,a second level of subscriber authentication is achieved. The values ofthe PINs are controlled locally at enterprise server 415. Accordingly,system administrators at the enterprise server have control of thesecond authentication level, and therefore final control over whichsubscribers are allowed to access the enterprise network information.

[0098] From the point of view of EGS 164, CDO object 604 is executinglocally at data center 190. EGS 164 accesses DCOM proxy 607 as if itwere a locally executing CDO object. Proxy 607 converts the CDO requestsfrom EGS 164 to the previously mentioned higher level, less messageintensive protocol, and transmits the request through the session tunnel608 to DCOM stub 605. Thus, calls across network 402 are handledtransparently to EGS 164. Additionally, dropped or lost tunnels to DCOMstub 605 are reinitiated by DCOM proxy 607 and DCOM stub 605 withoutinvolving EGS 164.

[0099]FIG. 7B is a conceptual diagram illustrating the communicationpath between messaging server 410 and EGS 164 when DCOM proxy 607 andDCOM stub 605 are used. As shown, CDO 604 communicates with messagingserver 410 using multiple CDO requests 712. DCOM stub 605 aggregates theresults of a number of CDO requests and transmits it to DCOM proxy 607over an encrypted session tunnel. Proxy 607 converts the aggregatedresults into CDO messages for EGS 164.

[0100] 5. Additional Attributes

[0101] The system further includes the ability to personalize orcustomize the subscriber interface based on the status or desire of thesubscriber or the enterprise network 403. For example, the partymaintaining the enterprise network 403 may wish to introduce certaingraphics or data when a subscriber logs in or seeks data from theenterprise. Coupled with this is the desire of a subscriber to configurehis or her account to show certain information; for example, when thesubscriber is operating a device at his workplace, he may wish to onlyreceive work related e-mail. Alternately, the subscriber may havelanguage preferences or screen style preferences that he or she wishesto view on particular devices.

[0102] The subscriber enters his preferences, which are stored in theSQL server in the login subsystem 140. These features may includebackground color, primary and secondary colors, or other preferences forthe subscriber interface. When the subscriber accesses the service, thelogin server 142 receives the carrier, enterprise, language, and browserinformation from the signal received.

[0103] The set of customizable elements are identified by a sequencecalled the customization ID. The customization ID represents a uniquecombination of carrier, enterprise and language desired by theparticular enterprise. When a user logs into the system, theircustomized look and feel is determined by matching their carrier,enterprise and language preferences to the master set of customizationIDs. The system then fetches the matching custom elements. Thecustomized elements are inserted into ASPs at specific locations,thereby altering the look and feel of the system.

[0104] In many cases, enterprises do not customize every possibleelement of the service but simply change a small subset such as thebanner logo and primary colors. In these cases where many elements arenot customized, default values are retrieved so that the entire look andfeel is preserved when the page is being internally “assembled.”

[0105] The custom elements themselves are not fetched directly from theSQL Server during runtime but are stored as a structured array of valuesin memory on the server. Running in memory provides increasedperformance by minimizing database queries for custom elements. Thecustomization system “refreshes” itself during runtime by updating thein-memory structure arrays from the data in the SQL Server database.Changes to the customization system are therefore available real-timewithout the need to restart the system.

[0106] The system maintains a Customization table, which includes acorrelation between a specific combination of Carrier, Enterprise andLanguage and a unique Customization ID, i.e., [Provider X; Company Y;French Canadian] is CustomizationID #6. This combination of factors, orCustomization ID, is in turn related to a set of customized elements.The number and variety of customizable elements can be extensivedepending on resource availability, and can range from the backgroundcolor of the page to the text within the subject header of the e-mail inbox. The CustomElementNames table maintains the master list of all ofthe customizable elements supported. TABLE 1 CUSTOMELEMENTSNAMES TABLEELEMENTNAME SortOrder Note Example CarrierBannerLog 1 HTML <img src =“images/default/att_logo.gif”> MainBgColor 1 Hex Color #FFFFFFPpcBannerLogo 5 Text Revolv Home HdmlPhoneAboutText 4 HDML<LINE>Wireless Knowledge<LINE>LLC

[0107] The system stores the customized elements are in theCustomElements table that maintains a correlation between a specificCustomization ID and all of the customizable element names and theirassociated values. By having the CustomElements table track elements asname/value pairs, elements may be removed or added without modifying thetable structure. Element values can be HTML, HDML, XML, hex values plaintext or any other textual information. TABLE 2 CUSTOMELEMENTS TABLECUSTOMIZATIONID ElementName ElementValue 1 CarrierBannerLogo <img src =“images/default/WKBanner.jpg” width = “270” height = “70”border = “0”> 1PhoneHomeTitle Revolv Home 5 CarrierBannerLogo <img src =“images/bm/ServiceProviderXBanner.jpg” width = “300” height = “70”border =“0”> 6 PhoneHomeTitle Service ProviderX1

[0108] When a user logs in, the system obtains the user's CarrierID,EnterpriseID and LanguageID from her record in the Users table. Thesystem then compares these three values against the Customization table,looking for a match. If an exact match is not found, the system searchesfor the closest match in the following order of precedence:

[0109] a. Look for a matching CarrierID, EnterpriseID, and LanguageID

[0110] b. Look for a matching CarrierID, EnterpriseID and defaultlanguage

[0111] c. Look for a matching CarrierID, no enterprise and LanguageID

[0112] d. Look for a matching CarrierID, no enterprise and defaultlanguage

[0113] e. Use the default look and feel

[0114] Based on the closest match, the system determines theCustomizationID. As may be appreciated, the enterprise dictates certaincomponents of the Customization ID. Should no enterprise dictatedparameters be available, the system may provide the user with theability to dictate preferences for appearance, and if the user has notindicated the information, the default appearance is presented to theuser.

[0115] Application startup procedures are presented in FIG. 8. Onapplication startup, the system builds the pCustomization Index array801 by parsing the Customization table 802 and ordering theCustomizationID's sequentially. This array will later be used as an “rowindex” for the pElementValues array 806. The system then builds thepElementNames array 803 by parsing the CustomElementNames table 804. ThepElementNames array 803 serves as the “column index” for thepElementValues array 806. The system then populates the pElementValuesarray 806 by parsing the CustomElements table 805. Each row of thepElementValues array 806 corresponds to a specific element found in thepElementNames array 803, and each column of the pElementValues array 806corresponds to a specific CustomizationID from the pCustomizationIndexarray 801. The CustomElements table 805 is parsed and the values arepositioned within the pElementValues array 806 according to theElementName and CustomizationID for each record.

[0116] Once the system has populated the pElementValues array 806, thearray is parsed and each row is stored in a variant array 807. Eachvariant array is then stored in an Application variable with the samename as the array element, i.e., Application (“CarrierBannerLogo”).

[0117] Each application includes the customization library in its globalvariable definitions. This file contains all of the functions needed bycustomization. The Application₁₃OnStart subroutine calls theinitCustomization( ) function, which performs the first-run parsing ofthe database tables and the storage of the customized elements intoApplication variables. This function loads the latest customizedelements from the database and populates Application variables withvariant arrays containing these elements.

[0118] The system determines the user's CustomizationID by examining herCarrierID, EnterpriseID and LanguageID and finding the CustomizationIDthat is the closest match. Once the CustomizationID has been determined,the system compares it to the CustomizationIndex array to determinewhich array positions contain the customized elements for this user.This derived value is called the User Customization Index value and isstored in a Session variable (or carried along the query string forPhone code). The getUserCustomizationIndex( ) function returns a valuerepresenting the ordinal position of customized elements for theparticular user. Since all of the customizable elements of the serviceare stored as variant arrays within Application variables for eachapplication they are easily accessible from ASP. Each page that needscustomization must have the getElement( ) function included, whichreturns a string value representing the customization element for aspecific Customization ID. For efficient operation, each occurrence of ahard-coded element (HTML or otherwise) must be replaced with thegetElement( ) function. Each web application needs to have an ASP pagethat calls the initCustomization( ) function, passing an argument todisplay the customized contents as they are populated into Applicationvariables.

[0119] The system further provides for notification in circumstanceswhere the user requests to be notified on a particular input deviceunder predetermined conditions. When the subscriber receives acommunication that he or she has established to be important, such as ane-mail message having a designation of urgent, the system attempts tonotify the subscriber. The subscriber states his or her preferences fornotification, such as what events trigger a notification and which inputdevice or devices should be notified of the triggering event. Thesenotification indications are maintained in the SQL server at the datacenter 190, and this information is periodically monitored. As may beappreciated, only certain events will require user notification. Withdata information limited to e-mail, calendar, and contacts, notificationwill not be required for contacts, and certain e-mail requests mayrequire notification. Calendar items may also prompt notification. Insuch circumstances, the user preference may require monitoring at theremote enterprise by passing the requested notifications to the remoteenterprise location. Alternately, notification may monitor user requestsat the data center 190, with requests periodically transmitted to theenterprise servers. The problem with maintaining the information at thedata center 190 and transmitting requests to the enterprise server isoverhead. In the scenario where the data is provided to the enterpriseserver, the enterprise server maintains the preferences for all users inits domain, such as notification of an urgent e-mail, and when thecondition is true, passes information to the data center 190. Datacenter 190 correlates the notification with the various input devicesrequested to be notified by the user, and transmits the data to the userinput device requested.

[0120] A-further aspect of the current system is the ability for thesystem to determine the type of device accessing the system. Forexample, the system receives information over a data line includinginitialization information, account information, passwords, and soforth, in addition to browser information. Browser information includesthe information requested for the type of browser used, e.g. aMICROSOFT® Windows CE device indicates that it is using a Windows CEcompliant browser. Included in the browser information is headerinformation from which the data center 190 can determine the type ofdevice transmitting the data. The data center 190 stores the informationexpected to be received from a particular browser; for example, theNetscape browser, used on desktop and laptop devices, may include theword “mozilla” in its header information. The data center 190 maintainspredetermined expected header parameters for each anticipated inputdevice. This predetermined information is maintained in the SQL server.Upon connection between the input device and the data center 190, thedata center retrieves the browser header information and compares thisinformation with the predetermined information and, if it determines amatch, interfaces with the input device with input device specific data,e.g. screen size limitations, colors/greyscale data, and so forth. Thusthe system does not require user input to determine the type of deviceaddressing the data center 190 and can transmit appropriate input devicespecific data to the user.

[0121] Further, as may be appreciated from the foregoing description,the data center interacts with the enterprise network by transmittingrequests to the enterprise network and receiving responses therefrom. Asmay be appreciated, a user desiring access to the data center will inmost circumstances also wish to have access to the enterprise network.For security reasons, an enterprise network may not wish the data centerto directly access the enterprise, and will not automatically grantaccess. Most enterprise networks will have firewalls installed toprohibit access by unknown parties.

[0122] The system accepts passwords for access to the data center andthe user logs into the data center. Subsequent to this logon, the systemknows the enterprise where the user may access information based on theuser's profile. The user then is provided by the data center to theenterprise network, where the user must log into the enterprise. Thiswill typically be a different user name and a different password.Certain password evaluation algorithms are employed by the data centerto guard against access by unauthorized parties. However, under allconditions, the data center never obtains the user's enterprisepassword, but merely passes the user's password through to theenterprise without storing or evaluating the information.

[0123] The foregoing description of preferred embodiments of the presentinvention provides illustration and description, but is not intended tobe exhaustive or to limit the invention to the precise form disclosed.Modifications and variations are possible consistent with the aboveteachings or may be acquired from practice of the invention.Accordingly, the scope of the invention is defined by the claims andtheir equivalents.

What is claimed:
 1. A data center providing access to subscriberinformation maintained on a remote enterprise network, the data centercomprising: a data network interface system for interfacing with a firstdata network; a login system including a login server for receiving, viathe data network interface system, a request inputted by a subscriber ona remote access device across the first data network to access thesubscriber information and for authenticating the subscriber and theremote access device; and a service system including a plurality ofenterprise gateway servers, each corresponding to a remote accessdevice, for transmitting the request to the remote enterprise networkacross a second data network to the remote enterprise network and forreceiving the requested subscriber information from the remoteenterprise network across the second data network; wherein the loginserver dynamically redirects the remote access device to a correspondingenterprise gateway server associated with the enterprise network uponauthenticating the subscriber and the remote access device, and thecorresponding enterprise gateway server establishes a virtual privatenetwork (VPN) connection with the remote enterprise network across thesecond data network and communicating with the remote enterprisenetwork.
 2. The data center of claim 1, wherein the request to accessthe subscriber information conforms to a Hypertext Transfer Protocol(HTTP) request and includes information referencing the data center,information identifying the type of remote access device, and a UniformResource Locator (URL) identifying the remote enterprise data network.3. The data center of claim 2, wherein the login server, upon receivingthe HTTP request, transmits a message to the remote access deviceprompting the subscriber to input login credentials and a PersonalIdentification Number (PIN).
 4. The data center of claim 1, wherein thelogin system further includes an attributes database server hostingsubscriber credentials for authenticating the subscriber, the attributesdatabase server being accessed by the login server.
 5. The data centerof claim 4, wherein the login server compares information from the HTTPrequest and login credentials to the subscriber credentials toauthenticate the subscriber and the remote device.
 6. The data center ofclaim 5, wherein the login server supplies an enterprise access code tothe remote access device and the corresponding enterprise gateway serverto provide a secure dynamic redirect to the remote enterprise network.7. The data center of claim 1, wherein the data network is a wirelesscommunication network.
 8. The data center of claim 1, wherein the datanetwork interface system includes at least one of a firewall and aperimeter router for restricting access across the wireless network. 9.The data center of claim 1, wherein the second data network is a widearea network (WAN).
 10. The data center of claim 4, wherein the servicesystem includes application interfaces which operate with the loginserver, the attributes database server, and the plurality of enterprisegateway servers, to identify the remote access device, to process theauthentication of the subscriber and the remote access device, todynamically redirect the remote access device to the correspondingenterprise gateway server, to establish the VPN connection between thecorresponding enterprise gateway server and the remote enterprisenetwork, and to transmit the requested subscriber information to theremote access device.
 11. A data center providing access to subscriberinformation maintained on a data center messaging server, the datacenter comprising: a data network interface system for interfacing witha data network; and a login system including a login server and a datacenter messaging server, the login server receiving a request inputtedby a subscriber on a remote access device across the data network, viathe data network interface system, to access the subscriber informationand authenticating the subscriber and the remote device, the data centermessaging server hosting the subscriber information, wherein the loginserver, upon authenticating the subscriber and the remote device,accesses the subscriber information on the data center messaging serverand provides the subscriber information to the remote access device inresponse to the received request.
 12. The data center of claim 11,wherein the request to access the subscriber information conforms to aHypertext Transfer Protocol (HTTP) request and includes informationreferencing the data center, information identifying the type of remoteaccess device, and information identifying the subscriber information.13. The data center of claim 12, wherein the data network is a wirelesscommunication network.
 14. The data center of claim 12, wherein thelogin server, upon receiving the HTTP request, transmits a message tothe remote access device prompting the subscriber to input logincredentials.
 15. The data center of claim 11, wherein the data networkinterface system includes at least one of a firewall and a perimeterrouter for restricting access across the wireless network.
 16. The datacenter of claim 11, wherein login accesses an attributes database serverhosting subscriber credentials for authenticating the subscriber. 17.The data center of claim 16, wherein the data center includesapplication interfaces which operate with the login server andattributes database server to identify the remote access device, toprocess the authentication of the subscriber and the remote accessdevice, to access the subscriber information on the data centermessaging server, and to transmit the requested subscriber informationto the remote access device.
 18. The data center of claim 17, whereinthe application interfaces are further configured to transmit thesubscriber information request to the data center messaging server andto receive the requested subscriber information from the data centermessaging server.
 19. The data center of claim 18, wherein theapplication interfaces comprise a plurality of component object model(COM) objects and active server pages (ASPs).
 20. The data center ofclaim 11, wherein the login server is configured as web server.
 21. Thedata center of claim 11, wherein the login server is configured as anInternet Information Server (IIS).
 22. The data center of claim 16,wherein the attributes database server is configured as a StructuredQuery Language (SQL) server.
 23. The data center of claim 11, whereinthe data center messaging server is configured as an Exchange Server.